I don't think we need to link the GUI frontend with the main jj executable so long as the GUI relies on the same machinery as the external diff frontends. Bundling the default GUI editor might be nice, but they don't have to be the same executable.

I'm not sure why you feel this way, how strong your feelings are, or if you see some approach here that I don't, so I just wrote down a bunch of my thoughts.

My goal here is to have a 0-configuration GUI that can work anywhere jj does. That's the main reason I took the time to make a tool that works from a local server (so, it works anywhere that has a web browser and over SSH). I think that a 3-pane diff editing experience is something that allows people to use jj in a powerful way they wouldn't be able to otherwise, so it's a good advertising for jj as well.

Requiring people to find, install, and configure the tool before they could use it would defeat most of its purpose. Anybody who can use and is willing to install Meld can use that already. On a Mac, or over SSH (to another machine, a VM, etc), using Meld is difficult or impossible even for people who are willing to put some time into it, and they get a sub-optimal jj experience in my opinion. (Or, at least, I'd like to get more people hooked on 3-pane diff editing, which is hard to explain to a new person but seems powerful to me, and intuitive once you try it).

I don't know an easy way to bundle the executables together without requiring configuration; getting jj to find the executable for diffedit3 automatically seems hard. In fact, if I wanted to bundle another executable with jj, I'd probably use something like rust-embed to include it into the binary. I was also hoping that linking them together would decrease the total size (since they use a lot of the same dependencies), but this didn't happen. I'm not sure why, so perhaps it could improve later :) (or not).

We can have the diff editor be a Cargo feature, so people who want to save 1.5MB of binary size could compile jj without it. (Also, perhaps this could be the default for incremental/debug builds)

IRC, we have :builtin TUI mainly because it does something that can't be achieved within the external diff interface.

I'm not sure that's true, what can it do that an external binary couldn't?

I was and am considering making it possible for jj call :builtin-web without having to materialize anything on disk, but that would take some extra work.

One way to think about it is as analogous to linking in a built-in pager on Windows. The difference is that there is no platform where a good enough diff editor is provided out of the box.

That said, this PR looks good as its own, thanks.

Thanks for the review! I'll merge it tomorrow, I think.

BTW, I'd prefer having a TUI three-pane-diff tool to a local server webapp, but that's harder to make. The easiest way for me would be to use Vim (improve the DirDiff extension or vimtabdiff), but plenty of people would never use something with Vim keybindings. I was considering making something based on https://github.com/zyedidia/micro, but it's a lot of work, the project is not very active, and overall it's just a lot less work to use CodeMirror and all the work that's already put into that.

IRC, we have :builtin TUI mainly because it does something that can't be achieved within the external diff interface.

I'm not sure that's true, what can it do that an external binary couldn't?

#2117 (comment)
(btw, it might be achieved by API server #3219)

So, yeah, I'm conservative regarding UI integration in general. I'm not sure why, but might be because:
UIs tend to be complex, fast moving, brings more dependencies, more flavors (web vs traditional), etc. And I personally don't find it's hard to set up third-party tools for my needs.

Anyway, it's not what I will decide.

I'm not sure that's true, what can it do that an external binary couldn't?
#2117 (comment)
(btw, it might be achieved by API server #3219)

Right, thanks for the reminder.

UIs tend to be complex, fast moving, brings more dependencies, more flavors (web vs traditional), etc.

Yeah, those are problems. I tried to keep this one as simple as possible, but there's only so much I could do.

And I personally don't find it's hard to set up third-party tools for my needs.

I've been working in a few environments (remote Linux, Chrome OS Linux, Mac OS), and Meld had different challenges on each one (have to use remote desktop on remote, problems with Wayland on Chrome OS, having to find and use https://gist.github.com/syneart/4a8724cd479d31f0f742f499f807dcb2 on Mac).

Anyway, it's not what I will decide.

Your opinion certainly has a lot of weight in my mind, even (especially?) when I don't immediately agree with it. I'm not quite sure what to do right now, I'm hoping the Discord discussion might produce something. I realized I started it at the wrong time for you, sorry.

I tried to keep this one as simple as possible,

Nice, I'm a bit surprised that the changes in Cargo.lock in your PR wasn't huge.

And I personally don't find it's hard to set up third-party tools for my needs.

I've been working in a few environments (remote Linux, Chrome OS Linux, Mac OS), and Meld had different challenges on each one (have to use remote desktop on remote, problems with Wayland on Chrome OS, having to find and use https://gist.github.com/syneart/4a8724cd479d31f0f742f499f807dcb2 on Mac).

That doesn't apply to diffedit3, right? I expect it would be super easy to install as it can be integrated in jj with a small amount of changes.
(I understand X11 forwarding isn't easy and not nice, and Meld is Python-based which has some other warts.)

Anyway, it's not what I will decide.

Your opinion certainly has a lot of weight in my mind,

As for packaging, I'm old man. I don't buy much about single binary, musl, etc. So feel free to disregard my comments around that.

That doesn't apply to diffedit3, right? I expect it would be super easy to install as it can be integrated in jj with a small amount of changes.

Yes, that's the idea. AFAIK, in all of these environments it's possible to start a server on a local port and start a browser to get a webpage from that port, like Jupyter does. In many of them, no setup would be needed; in some you'd need to SSH with port forwarding.

Another example of an environment where Meld is hard (mentioned by @thoughtpolice) is WSL.